What do you think guys?

Perfect! Thank you very much for integrating them!

I just had a look on this PR and in the IDE all seems fine. For testing I created a function

private @NonNull List<String> getList() {
        List<String> l = Collections.emptyList();
        return l;
    }

in ThingImpl (since for this project you enabled the external annotations) and there is no error on the return line. If I remove these lines

emptyList
 <T:Ljava/lang/Object;>()Ljava/util/List<TT;>;
 <T:Ljava/lang/Object;>()L1java/util/List<TT;>;

from Collections.eea I do get the warning on the return line.

But I maven this warning doesn't even appear, with or without the external annotations. Did you make some tests with maven and what were your results?

One question regarding the IDE support for adding additional annotations: The documentation you are linking to says that we need to have the source code for that library attached. So hoe did you configure your IDE to attach the source of the JDK? Can we have that as a general setting for everyone?

What do you think guys?

IMHO it generally makes sense in order to complete the null-annotations picture!

I'm just wondering whether it makes sense to start from scratch or if it rather makes sense to join forces with e.g. https://github.com/lastnpe/eclipse-null-eea-augments. It's not big yet, but it's a start and it somehow feels inefficient if every project again and again creates eea files for popular libs. Are you aware of it?

I installed the sources with every JDK on my machine and its always configured in the Eclipse IDE. So I haven't changed anything.

I didn't tound any external annotation project. Is this a well known one? Where is it linked?
As long as we need the files in a local directory, how do you think could this established using an external repository?

@maggu2810 Could you please give some insights on how you tested the external annotations with maven? I.e. do you have an example where maven now reports a warning which then disappears if you enable the external annotations?

I didn't tound any external annotation project.

@maggu2810 See here the start of that discussion: #3933 (comment)

Is this a well known one?

Well, it has been created by a good friend of mine because nothing adequate existed. Check his presentation from EclipseCon Europe last year (btw, this has interesting infos that might help us resolving our general open discussion points around null annotation usage). He worked on this jointly with Stephan Hermanns, the guy who has implemented the whole null annotation support in the Eclipse IDE - so I guess this is the closest to an "official" repo as we can get...

how you tested the external annotations with maven?

@triller-telekom Sorry, for the first step I didn't test it really.
If added the command line arguments as pointed out on some documentation and just looked that the build is not broken.
We need to investigate this.

Strange... I just tested the following and it works as expected:

Added method in ThingType.java

private @NonNull List<String> getList() {
        List<String> l = Collections.emptyList();
        return l;
    }

With Collections.eea as included in this PR everything is fine in IDE and maven. If I remove

emptyList
 <T:Ljava/lang/Object;>()Ljava/util/List<TT;>;
 <T:Ljava/lang/Object;>()L1java/util/List<TT;>;

from this file then I get a warning in the IDE on return l and:

this maven result:

Null type safety (type annotations): The expression of type 'ThingTypeUID' needs unchecked conversion to conform to '@NonNull ThingTypeUID'
[WARNING] /home/stefan/smarthome-master/git/smarthome/bundles/core/org.eclipse.smarthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/type/ThingType.java:[51] 
        return l;

So all is working as expected?

So all is working as expected?

Hopefully, if something is not working as expected, we could fix it later, too.

But we need to wait for the CQ.

I do not think that this is the best way to move forward.
Imho, we need to differentiate between two groups of users:

1. Consumers of the annotations (e.g. the Maven build or binding developers, who just need to have the eeas considered in their IDE/build).
2. External annotation maintainers

For the first group, requiring the eeas on the local file system / within the workspace is imho a no-go. Note that most binding developers e.g. work with the openHAB 2 IDE, which (normally) does not require a checkout of the ESH project at all for development. In general, it goes very much against any "minimal IDE requirements" (see also regular questions about compiling against pure Maven ESH artefacts / bnd support / etc.) to require such a project in the workspace.
I didn't dive into eea support deeply yet, but from a first glance it seems that it is perfectly possible to reference eeas from the build classpath, so there should be no need for source projects.

For the second group: This is really nothing specific about ESH, so I do not see why this should be specifically maintained in our repo. As @SJKA pointed out above, there is already a place that intended to be the shared place for the whole community. Did you already check whether it could be an option for us to participate in it?

We are talking about external annotations here for third party libraries that are used by the ESH bundle developement. This does not need to be the same third party bundles that products consuming ESH bundles. For consuming ESH bundles EEA shouldn't be necessary. Or do I miss something here.

Or do we need to maintain the external(!) non-ESH annotations for non-ESH bundles, too?

Have you ever looked at the number of EEA in the repo @SJKA?
Why should we use that one that is not under control of the ESH committers?

At which place do you think to host that eea-jars so it could on build time?

Feel free to create a PR against my branch if you found a suitable solution.

We could create an artifact from the eclipse-external-annotations so you could use it in openHAB (for the consumers you pointed in (1)).
But I assume we need to differ between JRE and other ones because a product does not need to use the same versions and so nullness annotated stuff.

For ESH it would be (at least the first months) better to host it in the ESH repo as after some hours of usage you will add a lot of annotations. Moving this to an external one should be done after no more or rare annotations of JRE are added.
But it could be bad if we need to wait until someone release a new version of eea to use it in ESH...

Hello! I'd love to get you guys involved in lastnpe.org... Didn't have much time for it recently, but have been meaning to pick it up, so this is perfect timing. I'll be merging pending PRs ASAP, and publish that Eclipse plug-in for M2E integration somewhere. Perhaps you guys would like to contribute your EEAs there?

@vorburger The contribution of the EEA is no problem. Regardless of the decision we take here, I will create a PR for the Java 8 EEA to your repository.

But for the current situation I don't think it would be a good decision to use the EEAs of an external repository.
If we would use an external project "directly" that hosts that EEAs and find new annotations to add, we need to create a PR, wait until the maintainer / committer merge the PR, create a new release of the EEA artifact, ...
At some time if the most classes are part of the external annotations this is not a problem, but currently it would make IMHO more sense to have this EEA in a local directory to be consumed as soon as it is added.
After some annotations has been added or changed, a good guy should merge this to your repo and create a PR.

If we would use an external project "directly" that hosts that EEAs and find new annotations to add, we need to create a PR, wait until the maintainer / committer merge the PR, create a new release of the EEA artifact, ...

@maggu2810 I think we agree that the released artifact is only relevant for the "consumers" - releasing such a jar to Maven central would actually much easier from lastNPE than doing that from ESH.
For people like us who quickly want to create new annotations and share them with other ESH committers asap, there is imho no reason against having the annotations in the workspace (but it doesn't really matter whether it is a checkout of ESH or lastNPE as long as we would not have to commit this info in the project's .classpath files (can we keep that somehow as a workspace setting, @vorburger do you know?). And yes, once we add stuff, we would have to create a PR, but if I read https://github.com/lastnpe/eclipse-null-eea-augments/blob/master/README.md#contribute correctly, we should gain committer rights after the first 3 contributions, so there won't be any "wait until merge" part. And from the IDE we can work on the master branch and don't have to wait for releases.

But I assume we need to differ between JRE and other ones because a product does not need to use the same versions and so nullness annotated stuff.

That's an interesting question. @vorburger are the annotations specific for a certain version of a lib? In https://github.com/lastnpe/eclipse-null-eea-augments/tree/master/libraries/guava, I cannot find any information about which Guava version the annotations are actually meant for. So how could lastNPE possibly be a globally shared repo if everyone uses different versions of the libs?

@vorburger What is the correct place to ask you some questions related to the project?

I'll be merging pending PRs ASAP

• What about the ctron's PR from Dec 13, 2016
• With respect to the TODO list (latest update Dec 2, 2016) has there been any progress?
  Is I has been informed about EEA I asked my why not using the already present checker annotations? AFAIK most (all?) parts of the JRE are already annotated. Why starting from scratch and not reuse what is already present?
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=449653#c4 (2015) pointed to a location that contains already a lot of EEA for the JRE. Why is this not used?
• Why do your eea gav marker miss the version?
• You added to some of the POM that the version of the annotated library should be part of the artifact name of the eea annotation. Is this correct?
• Shouldn't the eea dependencies in the pom be marked optional and / or provided so they are not transitive dependencies that pollute the classpath while building other artifacts that depend on a artifact using EEAs?
• In the Eclipse IDE we can e.g. set eea for the JRE and for plug-in dependecies.(one for all) and that are stored in a setting file of the project. Using EEA for specific dependencies version are not saved and (at least it seems for me) the setting is lost after restart. Using that approach there will be only one directory for all dependency annotations that combines all packages (without differ between library, version, etc). Correct?
• Can you give us some hints how this could be set up optimal for the ESH project?
• It seems to me that the Eclipse IDE create / edit EEA support only handles "mark as nullable / non-null", so mark a type as 0 or 1, but misses the "+". Is this correct? If my understand of all that stuff is correct (and at least the evaluation seems to work this way), the "+" is fundamental if classes using generic types are used.

need to create a PR, wait until the maintainer / committer merge the PR
but if I read lastnpe/README correctly, we should gain committer rights after the first 3 contributions

Confirming - that's still very much my intention. @kaikreuzer you've just been invited as committer... ;-)

create a new release of the EEA artifact

lastnpe/eclipse-null-eea-augments#14 ?

not have to commit this info in the project's .classpath files (can we keep
that somehow as a workspace setting, @vorburger do you know?)

https://github.com/lastnpe/eclipse-external-annotations-m2e-plugin ?

Why do your eea gav marker miss the version?
You added to some of the POM that the version of the annotated library should be part of the artifact name of the eea annotation. Is this correct?
are the annotations specific for a certain version of a lib?

The intention is Yes, but we probably haven't completely thought this through yet. Open an issue, and help? :)

@vorburger What is the correct place to ask you some questions related to the project?

https://github.com/lastnpe/eclipse-null-eea-augments/issues

With respect to the TODO list (latest update Dec 2, 2016) has there been any progress?

Your Contributions to some of the ideas in the TODO and/or open GitHub issue are most welcome! ;-)

why not using the already present checker annotations? AFAIK most (all?) parts of the JRE are already annotated. Why starting from scratch and not reuse what is already present?

Someone needs to write a tool that converts Checker annotations to Eclipse.org JDT EEA format. Maybe you @maggu2810 ?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=449653#c4 (2015) pointed to a location that contains already a lot of EEA for the JRE. Why is this not used?

==> lastnpe/eclipse-null-eea-augments#10

Can you give us some hints how this could be set up optimal for the ESH project?

hopefully the slides from my EclipseCon presentation can help you. I'm afraid I'll not have the bandwith to actually get involved in ESH to set it up for you. I'm however hoping to find the time to integrate lastenpe.org with another project I'm involved in by day for work, so may be once that is done it will be useful to you to look at that; see e.g. https://git.opendaylight.org/gerrit/#/c/47370/.

@vorburger I have edit my comment last night again, so I assume you didn't get a mail. Can you please have a look at the edit post again?
Sorry for that effort, will create a new post next time.

https://github.com/lastnpe/eclipse-external-annotations-m2e-plugin

It would be great if this plug-in makes the declaration in every .classpath file obsolete.

taken from the "m2e.jdt.annotationpath" property in POM files

POM properties are derived, so can we define that property in the root POM of the multi-module reactor and it is considered for every project by the eclipse-external-annotations-m2-plugin?

How it the path resolved by the plugin?

A short example:

(f) pom.xml
(d) bundles
        (d) bundle1
                pom.xml
        (d) sub-category
                (d) bundle2
                        pom.xml
(d) eea

I assume I could set the property in the root POM e.g. to eea so this directory is used.
In plain Maven project (without Eclipse IDE) this works only for builds that are started with in the directory of the room pom (WD: root). If you would like to build e.g. bundle1 and change the directory to bundle1 the relative path to "eea" cannot resolved anymore.

Does your plugin resolve the path always based to the POM location the property is defined?

If we need to define the property with a relative directory for ever bundle's POM, there is no real benefit using pom.xml instead of .classpath?

Can you give me some insights, I assume I miss there something.

Is there an exmaple multi-module reactor project that is using EEAs in a local directory and works for Maven builds and in the Eclipse IDE (with the respective plugin installed)?

@maggu2810 I do not want to further pollute this ESH PR's Conversation with lastnpe.org related conversations, and will disengage from this thread. We would love to see you join the party over on https://github.com/lastnpe/ and raise issues there (or, MUCH better, pull requests - speak in code not words!).

As per usual best practices, please be fine grained and have 1 actionable issue per specific topic, in the right place (e.g. https://github.com/lastnpe/eclipse-external-annotations-m2e-plugin/issues for your last point above re. the plugin, but https://github.com/lastnpe/eclipse-null-eea-augments/issues for anything related to the EEA hosted in that repo).

PS: Of course, anything that's really more to do with Eclipse' JDT null analysis itself than with the lastnpe.org stuff, please instead engage over on http://bugs.eclipse.org maybe e.g. Stephan will have a look (e.g. for whatever you meant by "..the Eclipse IDE create / edit EEA support only handles..").

I added the external annotation classpath setting to every .classpath file of the repository (also the archetype one). The attribute standalone="no" could be removed from the XMLs as it is optional and default is already no (it is present becasue the XML writer I used in my tool added it) -- I didn't remove it as long as it is not clear how we proceed at all.
At least the result works as expected.

Should I close this PR as there is no interest in in-tree EEAs?
Is there anyone working on another solution that is not using in-tree EEAs?

@triller-telekom Are you still on this or do you expect anybody else to follow up here?

I think it highly depends on this discussion, i.e. what happens if we decide to turn off warnings for null annotations. If turning off the warnings makes the eea problem disappear for us, I currently do not see the need for integrating them into ESH. If the errors that we would like to keep for null annotations somehow "cannot be silenced" without those eea, then we should integrate them.

@maggu2810 You might have seen that I created a new PR that fetches the EEAs from a maven repo and puts them on the classpath from where the compiler called via maven picks them up. This works fine.

I have also created a PR in the lastnpe repo to create one large jar file will all annotations to which we can refer to: lastnpe/eclipse-null-eea-augments#57

How ever I still see 2 open points here:

• We need to configure our Eclipse IDE to also pick up the annotations from the classpath, as I understood the plugin from @vorburger only supports that for maven type projects and not java type projects. I have created a discussion issue here: Discussion: Eclipse IDE Java projects + external annotations lastnpe/eclipse-null-eea-augments#58 Do you have any ideas here?
• The versioning of libraries is currently not taken into account at all, are we fine with that?

Your EEAs could go into the lastnpe repo so we will even save a CQ here :)

The versioning of libraries is currently not taken into account at all, are we fine with that?

yeah, we haven't had the need to give that much thought over on lastNPE.org - so new issue 'bout that!

@maggu2810 & @triller-telekom Is #4513 the successor for this PR, so that this should be closed?

As already written above, regardless of successor or not, this PR is closed as there is no interest in in-tree EEAs.

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/how-do-you-deal-with-jdt-static-null-analysis-limitations/95036/14